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REMARKS 

Claims 1, 4-7 and 27 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Barna et aL (U.S. Patent Application Publication Number 
2002/0046277, hereinafter "Barna") in view of Verma et al. (U.S. Patent Application 
Publication Number 2003/0224792, hereinafter "Verma"), claims 11-16 stand rejected 
under 35 U.S.C. § 103(a) as being unpatentable over Barna in view of Applicant 
Admitted Prior Art, and claims 8-10, 17, 20, 21, 23-26, 29, 31 and 32 stand rejected 
under 35 U,S.C. § 103(a) as being unpatentable over Barna in view of Krishnamurthi et 
al. (U.S. Patent Application Publication Number 2003/0174667, hereinafter 
"Krishnamurthi"). Respectfully disagreeing with these rejections but nonetheless 
amending the claims, the applicants request reconsideration of the outstanding 
rejections. However, no amendments have been made for the purpose of narrowing the 
scope of any claim. 

Claims 1 and 27 recite that conveying the PPP context information comprises 
conveying only types of PPP context information that are applicable to the target 

AR. The Examiner has asserted that this language is taught by Verma [0043, 0045- 
0052]. Verma [0043-0052] reads as follows (emphasis added): 

[0043] The call state data can take a variety of forms. For instance, in a data connection, 
the call state data raay include the sequence number of the last packet sent, Ns, and the 
sequence number of the last packet received, Nr, for connection 56. See RFC 2661. In a 
voice connection, the call state may include whether the mobile node has a call waiting or 
is part of a conference call. The call state data may also include coll state data relating 
to the PPP protocol or other connection oriented protocols. For instance, tunnel 
endpoint 250 may store the call state data for a virtual PPP session with a peer 
entity in remote client 20. See RFC 1661. One of ordinary skill in the art will recognize 
that a variety of types of call state data exist that may be advantageously preserved by 
applying the approach described in the present invention. 

[0044] Tunnel initiator 230 will also multicast a newly defined USER_MOVED message, 
shown as message 236 in FIG. 3, that also includes the MIN for the mobile node, the 
tunnel ID value assigned to connection 56 by tunnel initiator 230, the call ID value 
assigned to connection 56 by tunnel initiator 230, and call state data for connection 56. 
The message may also include the address for tunnel endpoint 250. 
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[0045] An IP multicast message will have a predetermined message type that uniquely 
identifies it as a database query in accordance with the present invention. IP multicasting 
is the transmission of an IP datagram to a "host group 1 ', a set of zero or more hosts 
identified by a single IP destination address. A multicast datagram is delivered to all 
members of its destination host group with the same "best-efforts'* reliability as regular 
unicast IP datagrams, i.e., the datagram is not guaranteed to arrive intact at all members 
of the destination group or in the same order relative to other datagrams. The membership 
of a host group is dynamic; that is, hosts may join and leave groups at any time. There is 
no restriction on the location or number of members in a host group. A host may be a 
member of more than one group at a time and a host need not be a member of a group to 
send datagrams to it. 

[0046] A host group may be permanent or transient. A permanent group has a well- 
known, administratively assigned IP address. It is the address, not the membership of the 
group, that is permanent; at any time a permanent group may have any number of 
members, even zero. Those IP multicast addresses that are not reserved for permanent 
groups are available for dynamic assignment to transient groups which exist only as long 
as they have members. See RFC 1 1 12 and RFC 2236 for further information regarding IP 
multicasting. 

[0047] After multicasting message 236, tunnel initiator 230 then sends a StopCCN 
message 342 containing the tunnel ID for connection 56, which is acknowledged by 
tunnel endpoint 250 with ZLB-ACK message 344 . However, tunnel initiator 250 has 
stored the information relating to connection 56 in the entry in the connection table 254, 
so connection 56, in effect, survives in a suspended state. 

[0048] The multicast message 236 is sent to a predetermined multicast address that is 
shared by all the tunnel initiators within a subnet that includes tunnel initiator 230. There 
is typically some correlation between the logical subnet of tunnel initiator 230 and the 
geographical area surrounding tunnel initiator 230 within which mobile node 20 is likely 
to be travelling. For purposes of the present example, tunnel initiator 240 shares the 
subnet with tunnel initiator 230 and will therefore receive USER^MOVED message 236, 

[0049] When tunnel initiator 240 receives the USER_MOVED message 236, it creates an 
entry in handoff table 244 that is keyed by the MIN value and includes the data from the 
message. Likewise, all other tunnel initiators that receive message 236 and are configured 
according to the present invention will create an entry in their corresponding handoff 
tables. 

[0050] When mobile node 20 enters the service area for tunnel initiator 240 and receives 
an agent advertisement from tunnel initiator 240, it will transmit registration request 402 
that includes its MIN value. Responsive to registration request 402, tunnel initiator 240 
will query handoff table 244 using the MIN value. Tunnel initiator 240 will find the entry 
for mobile node 20 that was created in response to message 236 and sends a newly 

defined TUNNEL HANDOFFJREQUEST message 412 that includes the MIN value, 

the tunnel ID value assigned to connection 56 by tunnel initiator 230, the call ID value 
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assigned to connection 56 by tunnel initiator 230, a new tunnel ID vaiue assigned to 
connection 66 by tunnel initiator 240, and a new call ID value assigned to connection 66 
by tunnel initiator 240. 

[0051] Tunnel endpoint 250 uses the MIN value from tunnel handoff message 412 to 
query connection table 254 for a corresponding entry and will find the entry created in 
response to the CDN message 332 in FIG. 4 having cause code=HANDOFR Tunnel 
endpoint 250 restores the call data information from the entry in connection table 254 for 
use with connection 66 established with tunnel initiator 240. Tunnel endpoint 
acknowledges tunnel handoff message 412 by sending 
TUNNEL_HANDOFF_RESPONSE message 416, 

[0052] Once ZLB-ACK message 416 is received in the new tunnel initiator 240, the 
status of connection 66 is substantially the same as the call state of connection 56 when 
data transfer over connection 56 ceased. With the call state for connection 56 established 
in tunnel initiator 240 and restored in tunnel endpoint 250, data transfer over connection 
66 may resume where it left off when mobile node 20 left the transmission area for tunnel 
initiator 230. 

However, the applicants submit that, as cited, Verma does not teach or suggest any 
limitation on the PPP / call state data that is conveyed, while claims 1 and 27 recite that 
conveying the PPP context information comprises conveying only types of PPP context 
information that are applicable to the target AR. The applicants submit that Verma, as 
cited, does not teach or suggest what types of PPP context information are 
conveyed or even indicate that there are different types of PPP information. As cited, 
Verma merely refers to PPP genetically, saying that the "call state data may also 
include call state data relating to the PPP protocol or other connection oriented 
protocols." Thus, the applicants submit that this portion of Verma cannot be said to 
teach or suggest anything about limiting (or how to limit) what call state data relating to 
the PPP protocol is conveyed. 

As amended claims 17 and 29 recite that the beginning of a period of low 
remote unit data activity triggers establishing the PPP link. The Examiner has 
asserted (with respect to original claims 5 and 21) that this language is taught by Barna 
[0035]-[0036], which reads as follows: 

[0035] The prior art conventionally sets up an A10 connection following an access 
specific layer 2 handoff (CDMA 2000, 3GPP2/IS2001 Specifications). This contributes a 
significant delay. To address this concern, and hence reduce the delay level, a proposed 
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fast handoff procedure sets up the AlO connection earlier in the handoff process and 
preferably before the issuance of the handoff command from the old (serving) PDSN. 
More particularly, the pre-setup of the AlO connection is accomplished after the target 
Base Station Controller (BSC) responds to the PDSN handoff request with an A9-Setup- 
A8 message. Pre-setup of the AlO connection provides the new (target) PDSN with the 
address of the old PDSN. The new PDSN then makes a handoff solicitation to the old 
PDSN. Responsive thereto, the old PDSN provides all the security, mobility, and PPP 
context information relating to the subscriber. 

[0036] Transfer of the PPP context information obviates the need to renegotiate the PPP 
link at the new PDSN following handoff and minimizes delay of link layer establishment. 
The address of the new PDSN is provided to the old PDSN in connection with the A9-AL 
disconnect to stop packet transmission to the old BSC in the radio access network, and 
this address is used to establish a path to tunnel the packets to the new PDSN. Following 
mobile station handoff, an A9-AL connect message is provided to trigger the resumption 
of packet data transmission using the PDSN-to- PDSN tunnel. 

However, the applicants do not see how this portion of Bama teaches that the beginning 
of a period of low remote unit data activity triggers establishing the PPP link. Should the 
Examiner maintain the rejection of claims 17 and 29, the applicants request that the 
Examiner provide a more detailed explanation of how Barna supposedly teaches or 
suggests what is claimed. 

Since none of the references cited, either independently or in combination, teach 
all of the limitations of independent claims 1, 17, 27 or 29, or therefore, all the limitations 
of their respective dependent claims, it is asserted that neither anticipation nor a prima 
facie case for obviousness has been shown. No remaining grounds for rejection or 
objection being given, the claims in their present form are asserted to be patentable 
over the prior art of record and in condition for allowance. Therefore, allowance and 
issuance of this case is earnestly solicited. 

The Examiner is invited to contact the undersigned, if such communication would 
advance the prosecution of the present application. Lastly, please charge any additional 
fees (including extension of time fees) or credit overpayment to Deposit Account No. 
502117 - Motorola, Inc. 
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Respectfully submitted, 
M. Nakhjiri et al. 




Jeffrey K. Jacobs 
Attorney for Applicant(s) 
Registration No. 44,798 
Phone No.: 847/576-5562 
Fax No.: 847/576-3750 
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